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FAST  ARITHMETIC  IN  MACLISP 
by 

Quy  Lmit  Stttla  Jr.  * 


lUcLISP  provldas  a coapiler  which  produces  nuaerical  coda  coapetitlve 
in  spaad  with  soaa  FORTRAN  iaplaaontations  and  yat  coapatibla  with  tha  rest  of 
the  NacLIBP  systaa.  All  nuaarical  prograas  can  be  run  under  the  HacLIBP 
Interpreter.  Additional  declarations  to  tha  coapiler  specify  type  inforaation 
which  allows  the  generation  of  optiaized  nuaerical  code  which  generally  does 
not  require  the  garbage  collection  of  teaporary  nuaerical  results.  Array 
accesses  are  alaost  as  fast  as  in  FORTRAN,  and  perait  the  use  of  dynaaically 
•llocated  arrays  of  varying  diaensions.  Here  we  discuss  the  iapleaentation 
decisions  regarding  user  interface,  data  representations,  and  interfacing 
conventions  which  allow  the  generation  of  fast  nuaerical  LISP  code. 


This  paper  was  presented  at  the  NACSYNA  Users  Conference,  Berkeley, 
California,  July  1977. 


Keywords:  nuaerical  code,  optiaization,  coapilers,  data  representations, 
dynaaic  allocation,  LISP,  NacLISP,  FORTRAN 
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Introduction 


For  sovoral  ytars  now  NacLISP  has  supportad  a coapllar  which  produces 
axtroMly  good  nuatrical  coda.  Naasuranants  aada  by  Fatasuui  indicate  that  the 
ganaratad  coda  is  coapatitiva  with  FORTRAN.  [Fataaan]  Expressing  such 
nuaarical  coda  does  not  require  the  use  of  special  nuaarical  language  anbaddad 
within  LISP,  in  the  Banner  that  soaa  higher-level  languages  allow  the  user  to 
write  aachina  coda  in  the  aiddla  of  a prograa.  Rather,  all  nuaarical  prograas 
are  coaplataly  coapatibla  with  the  NacLISP  interpreter.  The  coapller 
processes  the  interpreter  definitions  along  with  additional  nuaarical 
declarations.  These  declarations  are  not  required;  oaitting  thea  aerely 
results  in  slower  coapiled  coda.  For  convenience,  special  nuaaric  functions 
are  provided  which  carry  iapliclt  declared  type  inforaation  (such  as  ♦ and 
for  integer  and  floating  point  addition,  as  opposed  to  PLUS),  but  the  user 
need  not  use  thea  to  get  optiaized  nuaarical  code. 


Chanoes  to  the  NacLISP  Language 


The  priaary  change  to  the  NacLISP  language,  as  seen  by  the  user,  was 
the  creation  of  nuaarical  declarations  for  use  by  the  coapller.  A general 
ceapiler  declaration  aechanisa  was  already  a part  of  the  language,  so  adding 
the  nuaarical  declarations  was  not  difficult.  This  aechanisa  involves  writing 
a NacLISP  expression  beginning  with  the  word  DECLARE  and  followed  by  various 
declarations.  Declarations  nay  be  global  or  local.  Global  declarations  are 
written  by  theaselves  in  a file,  and  affect  all  following  functions;  local 
declarations  are  written  within  the  text  of  a NacLISP  function,  and  affect 
only  the  scope  of  the  construct  they  are  written  within. 

The  siaplest  new  declarations  are  stateaents  of  the  typos  of 
variables.  Recall  that  NacLISP  has  three  basic  nuaaric  types:  fixnua, 
flonuB,  and  blgnua.  These  are  (respectively)  single-precision  integers, 
single-precision  floating-point  nuabers,  and  arbitrary-precision  integers. 
Only  the  first  two  typos  can  be  operated  on  directly  by  hardware  instructions, 
and  so  they  are  the  only  typos  of  interest  to  the  coapller.  An  exaaple  of  a 
variablo  declaration: 

(DECLARE  (FIXNUN  I J R)  ; single-precision  integers 

(FLONUN  A B FOO  ZAP)  ; single-precision  reals 
(NOTYPE  SNURF  QUUX))  ;no  specific  type 


If  a variable  is  always  nuaoric  but  soaetiaes  aay  hold  bignuas,  it  aust  be 
declared  NOTYFE.  The  default  assuaption  is  that  a variablo  Is  NOTTPB  (that 
is,  aay  contain  any  NacLISP  data  object);  NOTYPE  declarations  are  prlaarlly 
useful  to  undo  previous  nuaeric  declarations. 

The  types  of  the  arguaents  and  returned  values  of  functions  aay  be 
slallarly  declared: 

(DECLARE  (FLONUN  (CUBE-ROOT  FLONUN) 

(INTE6ER-P0WER-0F-REAL  FLONUN  FIXNUN)) 

(FIXNUN  (FIBONACCI  FIXNUN) 

(LENOTH-OF-LI8T  NOTYPE)) 

(NOnPE  (BE1VEEN-ZER0-AND-0NE-PREDICATE  FLONUN))) 
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a FLONUn  result,  that  INTEGER-POWER-OF-REAL  takes  a FLONUD  and  a FIXNUN  and 
delivers  a FLONUN,  and  so  on.  The  types  of  the  argunents  could  also  be 
specified  by  using  a local  declaration: 

(DECLARE  (FLONUN  (CUBE-ROOT)))  ;global  declaration 

(OEFUN  CUBE-ROOT  (X) 

(DECLARE  (FLONUN  X))  ;local  declaration 
(EXPT  X .333333333)) 

The  result  type  aust  be  specified  by  a global  declaration,  however,  and 
declaring  the  arguaent  types  globally  also  can  help  the  coapiler  to  produce 
better  code  for  functions  which  call  the  declared  function. 

Arrays  aay  also  be  declared  globally  to  the  coapiler.  NacLISP  arrays 
coae  in  three  types,  which  are  essentially  FIXNUN,  FLONUN,  and  NOTYPE.  (Thera 
are  other  types  also,  but  these  do  not  concern  us  here.)  The  ARRAY* 
declaration  takes  a subdeclaration  spacifying  the  array  type;  the 
subdeclaration  in  turn  specifies  the  naaes  of  arrays  and  their  diaansions.  An 
exaaple: 

(DECLARE  (ARRAY*  (FIXNUN  TUPLE  1 TABLE  2) 

(FLONUN  VECTOR  1 NATRIX  2))) 

This  declares  TUPLE  and  VECTOR  to  be  one-diaensional  arrays,  and  TABLE  and 
MATRIX  to  bo  a two-diaensional  arrays.  (NacLISP  arrays  aay  have  up  to  five 
disMnsions.)  If  the  values  of  the  dlaensions  are  also  known  ahead  of  tiao,  a 
slightly  different  fora  aay  be  used: 

(DECLARE  (ARRAY*  (FIXNUN  (TUPLE  43)  (TABLE  3 S)) 

(FLONUN  (VECTOR  3)  (NATRIX  ? 17)))) 

This  declares  TUPLE  to  be  of  length  43,  TABLE  to  be  3 by  5,  and  NATRIX  to  have 
17  coluans  and  an  unknown  nuaber  of  rows.  Note  that  *?*  can  be  used  to 
denote  an  unknown  diaension  value;  even  partial  dlaanslon  Inforaation  can 
help  the  coapiler  to  optiaise  array  accesses. 

The  user  can  write  arithaetic  code  using  the  traditional  naaes  PLUS, 
DIFFERENCE,  TINES,  and  QUOTIENT;  these  functions  work  on  any  kinds  of 
nuabers,  even  bignuas,  and  adait  alxed-node  arithaetic.  In  the  presence  of 
type  declarations,  the  coapiler  aay  be  able  to  deduce  that  the  arguaents  are 
always  floouas,  for  exaaple,  and  produce  hardware  instructions  for  floating- 
poiat  arithaetic.  The  user  can  also  use  the  FIXSW  and  FL08W  declarations  to 
tell  the  coapiler  that  such  'generic*  arithaetic  will  always  involve  only 
fixnaas  or  only  flonuas. 

As  a convenience  to  the  user,  however,  several  versions  of  the  coaaon 
arithaetic  functions  are  provided: 


generic 

PLUS 

DIFFERENCE 

TINES 

QUOTIENT 

REMAINDER 

CCD 

OREATERP 

LESSP 


fixnua  only 


// 

\ 

W 

> 

< 


flonua  only 

♦S 

-S 

*s 

11% 


> 

< 
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EQUAL  > ■ 

EXPT  ^ (flxnua  cxpontHt) 

(The  division  functions  are  written  es  *//*  instead  of  "/*  because  */*  is  a 
NacLISP  escape  character.)  The  functions  in  the  last  two  coluans  are 
coapletely  equivalent  to  those  in  the  first  coluan,  except  that  they  convey 
additional  typo  Inforaation  about  their  arguaents  and  results.  (An  exception 
is  that  the  fixnua-only  functions  do  not  check  for  overflow,  so  in  a situation 
where,  for  exaaple,  100000000  and  100000000  were  aultiplied  together,  TINES 
would  produce  a blgnua,  whereas  * would  overflow  and  produce  a not*very> 
aeanlngful  flxnua.  The  flonua-only  functions  do  not  check  for  overflow 
either,  whereas  the  generic  functions  give  en  error  for  overflow,  and  either 
an  error  or  zero  for  underflow.) 


Changes  to  the  NacLISP  lapleaentatlon 

In  order  that  the  arithaetic  aachlne  Instructions  aight  be  used 
directly  on  NacLISP  nuaeric  data  objects,  it  was  necessary  to  aodlfy  NacLISP 
to  use  a unifora  representation  for  fixnuas  and  flonuas.  Before  the  fast- 
arlthaetic  scheaa  was  iaplaaented,  NacLISP,  like  aany  other  LISP  systeas,  used 
two  representations  for  single-precision  integers.  One  represented  the 
Integer  as  a pointer  to  a aachlne  word  containing  the  value,  in  the  sane 
aanner  as  floating-point  nuabers  were  represented.  The  other  encoded  the 
value  into  the  pointer  Itself,  using  pointer  values  which  were  otherwise 
worthless  because  they  pointed  at  code  instead  of  data  objects.  The 
aotlvatlon  behind  the  earlier  dual  representation  was  to  avoid  allocating 
storage  for  saall  Integer  values,  which  are  frequently  used.  (InterLISP  has 
for  several  years  *open-coapiled*  arithaetic  functions  as  single  aachlne 
Instructions.  [Teltelaan]  Unfortunately,  it  still  has  a dual  representation 
for  integers;  as  a result,  before  adding  two  nuabers  it  aust  call  a routine 
which  deteraines  at  run-tlae  the  representation  of  each  nuaber  and  converts 
each  into  a full  aachlne  word  representation.  Coapiled  InterLISP  code  also 
calls  a siailar  routine  for  floating-point  nuabers,  not  because  of  aultiple 
representations,  but  in  order  to  perfora  error-checking  as  coapletely  as  the 
interpreter  does.  This  run-tiae  checking  destroys  any  advantage  gained  by 
open-coapiling  the  arithaetic  instructions.) 

The  pointer  encoding  was  reaoved  froa  NacLISP  for  the  fast-arithaetic 
scheae,  and  all  nuabers  are  now  unifqraly  encoded  as  pointers  to  full  aachlne 
words  which  contain  the  aachlne  representations  of  the  values.  In  order  to 
avoid  allocating  storage  for  frequently  used  saall  integers,  there  are  several 
hundred  words  of  aeaory  containing  consecutive  saall  Integer  values,  and  saall 
integers  are  created  by  asking  a pointer  to  one  of  these  standard  locations, 
rather  than  allocating  a new  word  for  each  use  of  a saall  integer.  (NacLISP 
does  not  allow  the  words  used  to  contain  nuabers  to  be  aodlfled  in  the  way 
InterLISP  allows  using  the  SETN  priaitive  [Teltelaan],  so  there  is  no 
difficulty  in  sharing  such  words.  In  fact,  these  saall  integer  locations  are 
even  shared  aaong  all  the  NacLISP  processes  in  the  tiae-sharing  systaa  by 
Baking  thea  read-only.) 

Vhlle  arithaetic  on  bignuas  cannot  be  coapiled  as  standard  arithaetic 
aachlne  instructions,  their  representation  has  been  chosen  to  perait  sign 
( tests  to  be  open-coaplled.  A blgnua  is  a pointer  to  a word  which  has  the  sign 

of  the  blgnua  in  the  sign  bit  (and  in  fact  the  entire  left  half),  and  a 
pointer  to  a list  of  fixnuas  (which  represent  the  aagnitude)  in  the  right 
half.  Thus  all  nuabers  are  pointers  to  words  which  contain  tho  sign  of  tho 
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number  In  the  sign  bit,  end  such  functions  es  NINU8P  can  always  be  compiled  as 
single  machine  instructions. 

In  order  to  preserve  the  uniformity  of  the  function-calling  interface, 
it  was  decided  that  all  arguments  to  functions  must  be  valid  HacLISP  data 
objects.  On  the  other  hand,  it  is  not  desirable  to  have  to  "number  cons”  out 
of  free  storage,  with  the  garbage  collection  overhead  that  Implies , in  order 
to  pass  numbers  to  functions.  The  solution  used  was  to  introduce  two  extra 
pushdown  lists  (stachs)  called  the  fixnum  and  flonum  pdls.  The  storage  in 
those  pdls  appear  to  have  fixnum  or  flonum  data  typo,  but  they  are  allocated 
as  stacks  rather  than  as  garbage-collected  heaps.  These  stacks  can  be  used  to 
hold  temporary  numerical  values  and  the  velues  of  PROC  variables  which  have 
been  declared  to  be  numeric,  but  they  can  also  be  used  to  allocate  pseudo-data 
objects  compatible  with  NacLISP's  standard  number  representation.  A pointer 
to  a fixnum  pdl  location  xs  indistinguishable  from  an  ordinary  fixnum  for  most 
purposes;  it  is  a pointer  to  a full  machine  word  containing  the  numeric 
value.  A typical  coda  sequence  resulting  from  compiling  (FOO  (♦  A 5))  is: 


;assume  accumulator  1 has  the  pointer  value  of  a in  it 


HOVE  7,(1) 

AODI  7,8 
PUSH  FXP,7 
nOVEI  1,(FXP) 
CALL  l.FOO 
SUB  FXP,C1,,1] 


;get  the  machine  word  for  A into  accumulator  7 

;add  8 to  the  machine  word 

:push  resulting  word  into  fixnum  pdl 

:topy  fxp  pointer  into  argument  accumulator  I 

;call  foo 

; remove  pushed  word  from  fixnum  pdl 


To  the  function  FOO  the  pointer  passed  in  accumulator  1 has  the  precise  format 
of  a NacLISP  Integer:  a pointer  to  a machine  word  containing  the  integer 
value.  Note  that  the  value  of  the  variable  A may  itself  have  been  such  a "pdl 
number”:  the  HOVE  instruction  would  move  the  machine  word  value  into 
accumulator  7 whether  it  was  a pdl  number  or  an  ordinary  fxxnum. 

One  of  the  difficulties  of  using  stack-allocated  numbers  is  that  they 
have  a definite  lifetime;  on  return  from  the  function  they  are  passed  to, 
they  are  de-al located  and  no  longer  exist.  By  the  time  they  are  de-al located, 
there  must  be  no  more  pointers  to  that  word  accessible  to  the  user  program,  or 
else  subsequent  references  might  see  a wrong  value  because  the  pdl  word  was 
re-allocated  for  some  other  purpose. 

To  overcome  this  difficulty  the  notion  of  safety  was  developed.  A 
copy  of  a pointer  is  safe  if  it  can  be  guaranteed  that  the  copy  will  become 
inaccessible  before  what  it  points  to  is  de-allocated  if  the  pointer  in  fact 
points  to  a pdl  number.  Alternatively,  a use  for  a pointer  is  safe  if  that 
use  doesn't  require  a safe  pointer.  The  fast-arithmetic  compiler  does  some 
complex  analysis  to  detoraino  what  situations  are  safe.  Some  standard 
conventions  for  safety: 

[1]  A pointer  in  a global  (special)  variable  nay  have  an  indefinite  lifetime, 
and  so  putting  a pointer  in  a global  variable  is  unsafe.  It  follows  that  such 
a variable  may  net  contain  a pointer  to  a pdl  number,  since  we  cannot 
guarantee  such  a pointer  to  be  safe.  Consequently,  any  pointer  actually 
obtained  from  a global  variable  is  safe. 

[2]  Consing  a pointer  into  a list  cell  (or  using  RPLACA  to  put  a pointer  into 
an  existing  list  call)  is  similarly  unsafe.  Pointers  actually  occurring  in 
list  structure  must  therefore  be  guaranteed  safe. 

C3]  It  is  net  possible  to  return  a pdl  number  as  the  value  of  a function, 
because  there  weuld  be  no  return  to  the  code  to  de-allocate  it.  Therefore 
returning  a painter  from  a function  is  unsafe,  and  all  pointers  actually 
returned  from  functions  are  safe. 
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[4]  Passlno  a pointer  as  an  arpuMnt  to  a function  is  safe;  tharafora  pdl 
nuabars  (unsafe  pointers)  say  be  passed  as  arguaants  to  functions.  All 
function  arguaants  are  thus  potentially  unsafe.  They  aay  be  passed  on  down  to 
other  called  functions,  hjt  aay  not  be  returned  or  otherwise  used  as  if  they 
were  safe. 

[5]  Pdl  nuabers  aay  be  pointed  to  by  ordinary  coapilod  local  variables.  Such 
local  variables  aay  or  aay  not  have  unsafe  values,  depending  on  where  the 
values  caae  froa.  The  coapiler  aust  guarantee  that  when  the  value  of  a local 
variable  is  used  either  the  value  is  safe  or  the  use  is  safe. 

Suppose  we  wrote  a function  such  as: 

(DEFUN  ZAP  (A)  ((XMS  A 'FOO)) 

We  are  putting  the  arguaent  A into  a list  coll  (an  unsafe  use),  but  the 
arguaent  A is  also  (potentially)  unsafe.  In  this  situation  the  coapiled  code 
aust  create  a safe  copy  of  the  unsafe  pointer.  The  coapiled  code  therefore 
uses  a routine  PDLNfK  (*pdl  nuaber  aake*)  which  checks  for  a pdl  nuaber  and 
Bakes  a copy  by  doing  a nuaber  cons  if  necessary.  That  is,  if  the  pointer 
given  to  PDLNHK  is  already  safe,  it  is  returned  as  is;  but  if  it  is  unsafe,  a 
safe  copy  is  Bade  with  the  sane  va'^ue.  The  coapiled  code  for  ZAP  would  look 
like  this: 

NOVEI  Z, 'FOO  ;put  constant  *foo*  in  accuaulator  2 

JSP  T,POLNIK  ;Bake  sure  accuaulator  1 has  a safe  pointer 

JCALL  2,C0NS  ;call  CONS 

If  A is  not  a pdl  nuaber,  PDLNMC  does  nothing;  but  if  it  is,  PDLNNK  replaces 
the  pointer  in  accuaulator  1 with  a freshly  allocated  fixnua  with  the  saae 
value  as  the  pdl  nuaber.  In  this  way  a safe  value  will  be  passed  to  the  CONS 
function.  (The  convention  about  function  arguaents  being  potentially  unsafe 
has  an  exception  in  CONS,  so  that  CONS  itself  need  not  always  perfora  PDLNHK 
on  its  arguaents.  The  coapiler  knows  about  this  exception,  and  guarantees 
that  anyone  who  calls  CONS  will  provide  safe  arguaents.  In  practice, 
arguaents  passed  to  CONS  often  can  be  guaranteed  safe  by  coaplle-tiae 
analysis,  and  it  saves  tlae  not  to  have  CONS  use  PDLNHK.) 

Notice  that  one  consequence  of  the  use  of  PDLNHK  is  that  two  nuabers 
which  are  apparently  EQ  (l.e.  the  saae  pointer)  aay  not  be  if  the  coapiled 
code  has  to  aake  a copy.  For  exaaple,  consider  this  code: 

(OEFUN  LOSE  (X) 

(SETQ  G X) 

(EQ  X 0)) 

The  result  of  the  EQ  test  could  be  NIL,  even  though  the  global  variable  G 
apparently  is  assigned  the  saae  pointer  at  was  pasted  to  LOSE  as  an  argument. 
If  an  unsafe  pointer  is  passed  to  LOSE,  0 will  receive  a safe  copy  of  that 
value,  which  will  not  be  the  sane  pointer,  and  to  the  EQ  test  will  fall. 
(This  is  another  reason  why  HacLISP  does  not  have  a SETN  priaitive;  since  the 
coapiler  can  aake  copies  of  a nuaber  without  warning,  conceivably  SETN  night 
■odify  one  copy  of  a nuaber  but  not  the  other,  with  anoaalous  results.) 

Recall  that  one  unsafe  use  of  a pointer  is  returning  it  as  the  value 
of  a function.  Va  would  like  for  nuaeric  code  not  to  over  have  to  "nuaber 
cons”,  but  wo  cannot  return  a pdl  nuaber  froa  a function.  The  solution  to 
this  diloaaa  is  to  allow  nuaoric-valued  functions  to  have  two  entry  points. 
One  is  the  standard  HacLISP  entry  point,  and  is  coapatible  with  the  standard 
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NacLISP  calling  stquanca;  calling  tha  function  thorn  will  produco  a NacLISP 
pointer  value,  which  will  involve  a nuaber  cons  if  the  value  is  in  fact 
nuaeric.  The  other  is  a special  entry  point  which  is  non-standard,  and  can 
only  bo  used  by  coaplled  code  which  knows  that  the  called  function  is  nuaeric- 
valued.  Entering  a nuaeric  function  there  will  deliver  a aachine  word  in 
accuaulator  7 instead  of  the  standard  pointer  in  accuaulatbr  1. 

In  order  to  use  this  special  calling  sequence,  both  tha  called 
function  and  the  calling  function  aust  be  coapiled  with  declarations 
specifying  that  the  called  function  is  nuaeric-valued.  The  coapiler  will  then 
coaplle  the  celled  function  to  have  two  entry  points,  and  the  calling  function 
to  use  the  non-standard  nuaeric  entry  point. 

The  entry  points  are  actually  iapleaented  as  two  consecutive  locations 
at  the  beginning  of  the  function.  The  first  is  the  standard  entry  point;  it 
aarely  pashes  the  address  of  a special  routine  FIXl  (or  FLOATl,  for  a flonua- 
valued  function)  onto  the  stack,  and  than  falls  into  the  non-standard  entry 
point.  The  function  then  always  produces  a aachine  nuaber  in  accuaulator  7. 
If  the  function  is  called  at  tha  nuaeric  entry  point,  it  will  deliver  its 
value  as  a aachine  word.  If  called  at  the  standard  entry  point,  than  on 
delivering  the  aachine  word  it  will  "return*  to  FIXl,  which  perforos  a "nuaber 
cons*  on  the  aachine  word,  producing  a nomal  flxnua  (or  FLOATl,  which 
produces  a flonua),  and  then  returns  to  the  caller. 

As  an  exaaple,  here  are  two  functions  with,  appropriate  declarations: 

(DECLARE  (FLONUN  (DISC  FLONUH  FLONUH  FLONUN))) 

(DEFIM  DISC  (A  B C) 

(-S  (*1  B B)  (*B  4.0  A C))) 

(DEFUN  QUAD  (A  B C) 

(PROQ  (D) 

(DECLARE  (FLONUn  D)) 

(SETQ  D (DISC  A B C)) 

(COND  ((NINUSP  D)  (RETURN  (ERROR))) 

(T  (RETURN  (//B  (-•  (SORT  D)  B) 

(•BA  2.0))))))) 


The  code  produced  would  look  like  this: 


DISC:  PUSH  P,[FLQAT1] 

HOVE  7,(2) 

FHPR  7,7 
NOVSI  10, (4.0) 
FHPR  10,(1) 

FNPR  10,(3) 

FSBR  7,10 
POPJ  P, 


;for  nomal  entry,  push  address  of  FLOATl 
; nuaeric  entry  point;  get  aachine  word  for  B 
; floating  nultiply  B by  Itself 
;get  4.0  in  accuaulator  10 
; floating  nultiply  by  A 
;floating  nultiply  by  C 
; floating  subtract  ac  10  froa  ac  7 
;aacbine  word  result  is  in  ac  7 


Notice  that  DISC  does  no  nunber  consing  at  all  if  called  at  the  nuaeric  entry 
point.  It  does  all  arithaetic  in  the  accuaulators,  and  returns  a aachine  word 
as  its  result.  The  code  is  reaarkably  coopact,  of  the  kind  one  ordinarily 
expects  froa  a FORTRAN  coapiler. 


;save  A,  B,  and  C on  tha  stach 
; to  preserve  thea  across  tha 
; call  to  DISC 


QUAD:  PUSH  P,1 

PUSH  P,2 
PUSH  P.3 
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NCALL  3, DISC 
PUSH  FLP,7 
JUHPGE  7,00003 
NOVEI  T.O 
CALL  16, ERROR 
JRST  G0005 

Q0003:  NOVEI  l.(FLP) 
NCALL  l.SQRT 
FSBR  7,0-l(P) 
HOVE  10,9-2(P) 
FSC  10,1 
FDVR  7,10 
JSP  T.FLCONS 

00009:  SUB  P,[3.,3] 
SUB  FLP,[1,,1] 
POPJ  P, 


;call  DISC  with  tha  sana  arsuaanta 
:push  tha  rasult  onto  flonua  pdl 
:JuBp  if  valua  non-nagatlva 

:call  tha  ERROR  routina 
:go  to  00009 

:oat  a pointar  into  flonum  pdl 
;call  SORT  with  that  pointar 
: floating  subtract  aachina  valua  of  B 
:fatch  otachina  word  valua  of  A 
;miltiply  by  2.0  (using  "floating  scala") 
:divida  ac  7 by  ac  10 
;parfora  a flonum  cons 
iclaan  up  tha  stacks 

:raturn  pointar  valua  in  accumulator  1 


Thare  are  savaral  points  to  nota  about  QUAD: 

(1)  It  was  not  daclarod  to  ba  nuaarlc-valuad.  As  a rasult,  whan  returning  a 
number  it  must  do  a number  cons.  Noraovar,  it  doas  not  have  a numeric  entry 
point. 

(2)  Because  DISC  was  declared  to  ba  numeric* valued,  QUAD  uses  NCALL  instead 
of  CALL  to  invoke  it;  NCALL  enters  at  the  numeric  entry  point.  The  result  of 
DISC  is  expected  in  accumulator  7.  Since  QUAD  needs  to  use  this  result  to 
pass  to  SORT,  it  makes  a pdl  number  out  of  this  machine  word.  In  this  way 
function  values  can  be  made  into  pdl  numbers  after  all  — but  by  the  caller 
rather  than  the  called  function. 

(3)  As  an  aside,  the  compiler  makes  some  other  neat  optimizations.  It  uses  a 
JUHPGE  instruction  for  NINUSP,  because  the  value  to  bo  tested  is  in  an 
accumulator  anyway.  It  takes  advantage  of  the  address  arithmetic  of  the  PDP- 
10  to  fetch  machine  words  pointed  to  by  pointers  on  the  stack  in  one 
instruction.  It  knows  how  to  use  several  accumulators  for  arithmetic,  and  to 
arrange  for  the  result  to  and  up  in  the  correct  accumulator.  It  expresses  the 
multiplication  by  2.0  as  a "floating  scale"  instruction,  which  is  faster  than 
the  multiplication  instruction  if  one  operand  is  a floating-point  power  of 
two. 

The  representation  of  arrays  in  NacLISP  was  carefully  redesigned  to 
allow  fast  access  to  them  by  compiled  code,  again  taking  advantage  of  the 
powerful  address  arithmetic  of  the  PDP-IO.  There  are  essentially  two  kinds  of 
arrays:  s-expression  arrays,  whose  components  nay  be  any  safe  pointers,  and 
numeric  arrays,  whose  components  must  be  all  fixnum  machine  words  or  all 
floDum  machine  words. 

The  NacLISP  ARRAY  data  type  is  a pointer  to  a double  word  (the 
"special  array  pointer")  which  in  turn  points  to  the  array  data.  The  reason 
for  this  is  that  the  pointer  must  point  to  a fixed  place  (as  all  NacLISP 
pointers  must),  but  the  actual  array  data  nay  have  to  be  shifted  around  by  the 
garbage  collector  to  accommodate  new  storage  requests,  because  arrays  are  not 
of  a uniform  size.  When  the  garbage  collector  moves  the  array  data,  it 
updates  the  the  contents  of  the  special  array  pointar,  but  the  special  array 
pointer  itself  nay  remain  in  a fixed  place. 

In  exchange  for  the  flexibility  of  dynamically  allocated  arrays, 
however,  one  pays  the  price  of  always  accessing  the  array  data  indirectly 
through  the  special  array  pointer.  This  cost  is  alleviated  by  taking 
advantage  of  addressing  arithmetic.  The  second  word  of  each  special  array 
pointer  points  to  the  array  data,  which  is  arranged  linearly  in  row-major 
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ord«r;  this  sscond  word  furthormors  specif los  indexing  by  eccusNilator  7. 
speciel  array  pointer 


■type  bits 

r TH 

jiC  inforaation 


header  code 


dlaenslon  1 
dlnension  2 

diaenslon  n 


elearant  0 
element  1 


element  {Dl». . .*Dnl-l 


array  data 


Compiled  code  can  access  a numeric  array  datum  by  calculating  the  linear 
subscript  value  in  accumulator  7 and  then  using  an  indirect  fetch  through  the 
second  word  of  the  special  array  pointer  for  the  array.  The  linear  subscript 
value  is  of  course  calculated  as 

{ ...  (J1  • 02  ♦ J2)  • D3  + J3  ...  ) « On  ♦ Jn 

where  the  Ni  are  the  dimensions  of  the  array  and  the  Ji  are  the  actual 
subscripts.  For  example,  suppose  that  accumulator  1 contains  a pointer  to  a 3 
by  5 by  13  fixnum  array,  and  that  accumulators  2,  3,  and  4 contain  flxnum 
subscripts  for  that  array.  Then  to  fetch  the  desired  datum  this  code  would  be 
used: 


i 


HOVE  7,(2) 
INULI  7,S 
ADD  7,(3) 
IHULI  7,13 
ADD  7,(4) 
PnVE  7,fl(l) 


: fetch  first  subscript  into  ac  7 
;multiply  by  5 (second  dimension) 

;add  in  second  subscript 
{multiply  by  13  (third  dimension) 

;add  in  third  subscript 

{fetch  indirect  through  special  array  pointer 


If  the  number  of  dimensions  of  the  array  has  been  declared  to  the  compiler  but 
not  the  values  of  the  dimensions,  the  compiler  arranges  to  fetch  the  dimension 
values  at  run  time.  This  is  easy  because  the  array  is  arranged  so  that 
negative  subscript  values  fetch  the  dimension  information.  (The  LISP  user  is 
not  supposed  to  use  this  fact,  but  only  compiled  code.)  The  same  example  for 
a three-dimensional  array  of  arbitrary  dimensions  might  look  like  this: 


HOVE  10,(2) 
HOVNI  7,2 
inUL  10,91(1) 
ADD  7,(3) 
NOVNI  7,1 
INUL  10,91(1) 
ADD  10,(4) 
NOVE  7,10 
NOVE  7,91(1) 


{fetcn  first  subscript  into  ac  10 

{put  -2  into  ac  7 

{multiply  by  second  dimension 

{add  in  second  subscript 

{put  -1  into  ac  7 

{multiply  by  third  dimension 

{add  in  third  subscript 

{move  into  ac  7 for  subscripting 

{fetch  Indirect  through  special  array  pointer 


The  code  la  a little  longer  than  before,  but  will  work  for  any  three- 
dimensional  array.  In  general,  the  compiler  tries  to  mlnimiie  subscript 
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computations.  If  the  exact  dimensions  are  declared,  or  if  some  of  the 
subscripts  are  constant,  the  compiler  will  do  part  or  all  of  the  subscript 
calculations  at  compile  time. 

For  s-expression  arrays,  the  pointer  data  are  stored  two  per  word, 
with  elements  having  even  linear  subscripts  in  the  left  half  of  a word  and  the 
succeeding  odd  subscripted  elements  in  the  right  half  of  the  word.  The 
compiler  must  generate  code  to  test  the  parity  of  the  linear  subscript  and 
fetch  the  correct  half-word.  Suppose  that  a pointer  to  a one-dimensional 
array  is  in  accumulator  1,  and  a Kxnum  subscript  is  in  accusailator  Z.  Then 
the  following  code  would  be  generated: 


G0006: 

G0007: 


HOVE  7,(2) 

ROT  7,-1 
JUnPL  7,G0006 
HLRZ  3,91(1) 
JRST  G0007 
HRRZ  3,91(1) 


; fetch  subscript  into  ac  7 
; divide  by  2,  putting  remainder  bit  in  sign 
;jump  if  linear  subscript  was  odd 
; fetch  pointer  from  left  half 
;jufflp  to  G0007 

; fetch  pointer  from  right  half 


If  the  compiler  can  determine  at  compile  time  that  the  linear  subscript  will 
always  be  odd  or  always  oven,  it  will  simplify  the  code  and  omit  the  JUNPL, 
JRST,  and  the  unused  halfword  fetch. 


Summary 


NacLISP  supports  the  compilation  of  numerical  programs  into  code 
comparable  to  that  produced  by  a FORTRAN  compiler  while  maintaining  complete 
compatibility  with  the  rest  of  the  NacLISP  system.  All  numeric  code  will  run 
in  the  NacLISP  interpreter;  additional  information  may  be  given  to  the 
compiler  in  the  form  of  declarations  to  help  it  generate  the  best  possible 
code.  If  such  declarations  are  omitted,  the  worst  that  happens  is  that  the 
code  runs  slower. 

Compatibility  with  non-numeric  functions  was  achieved  by  the  Judicious 
choice  of  a uniform  representation  for  LISP  numbers  combined  with  a compatible 
stach-allocated  representation  for  temporary  numeric  values  passed  between 
functions.  The  use  of  stack  allocation  reduces  the  need  for  garbage 
collection  of  numbers,  while  the  uniformity  of  representation  eliminates  the 
need  for  most  run-time  representation  checks.  One  exception  to  this  is  that 
the  use  of  stack-allocated  numbers  must  be  restricted;  this  difficulty  is 
kept  in  check  by  maintaining  a careful  Interface  between  safe  and  unsafe  uses, 
and  analyzing  the  safety  of  pointers  as  much  as  possible  at  compile  time. 

While  numeric  functions  and  non-numeric  functions  may  call  each  other 
freely,  a special  Interface  is  provided  for  one  numeric  function  to  call 
another  in  such  a way  as  to  avoid  number  conslng. 

Arrays  are  stored  in  such  a way  that  they  may  be  dynamically  allocated 
and  yet  accessed  quickly  by  compiled  code.  This  is  aided  by  the  rich  address 
arithmetic  provided  by  the  PDP-10. 

The  philosophy  behind  the  implementation  is  that  the  generality  of 
LISP  and  the  speed  of  optimized  numeric  code  are  not  incompatible.  All  that 
is  needed  is  a well-chosen,  uniform  representation  for  data  objects  suitable 
for  use  by  hardware  Instructions,  combined  with  a willingness  to  handle 
important  special  cases  cleverly  in  the  compiler. 
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